Types of Interviews

System design interviews#

Algorithms#

You don’t have to be an algorithms god, but you should know the basics, like having a passing familiarity with the main ideas in Gayle McDowell’s Cracking the Coding Interview or Emma Bostian’s Decoding the Technical Interview Process, memorizing and being able to derive the Big O’s of sorting algorithms, and so on.

Even a Google technical interview is at most 45 minutes of coding; that is not enough time to write a self-balancing red-black tree and barely enough to code up a heap sort from scratch. Just know the basics; Byte by Byte’s list of 50 Questions is indicative of the difficulty level of algorithm questions. Paid sites like Educative, Leetcode, and Algoexpert can help you practice.

Pro tip: “Interviewers generally want you to succeed, so they will often give hints. Use their hints. Failure to come up with some insight during a coding interview isn’t always a deal breaker. But ignoring an intentional tip or having poor communication skills usually is.” - Dan Abramov

Algorithm interviews make the most sense for people doing “low level” or “systems” programming. Data engineering and game development, in particular, have a strong focus on graph algorithms, whereas operating system and framework developers might need to be more familiar with data structures and dynamic programming.

However, the higher up in the coding career layers you are, the fewer algorithm interviews matter because you are less CPU or memory constrained. For most app developers, the failure of algorithm interviews to match actual work settings is well known. So, technical interviews have broadened to assess other forms of technical knowledge.

Technical interviews#

This topic is well covered by others and is very domain-specific, so it is out of the scope of this course, but definitely check out the Mega Interview Guide and Coding Interview University. However, the broad adage of “Make it work, make it right, and make it fast” applies.

As you tackle the problem, it’s important to explain your thinking process. A detailed framework you can use is the REACTO model:

• Repeat the question
• Come up with examples
• Outline your approach
• Code your solution
• Test your code
• Optimize your code

If you have a running environment to code in, it may be a good idea to do Test Driven Development for your code (flip the testing and coding stages). I once specifically got an offer because I chose to do TDD while trying to understand the question (It wasn’t a conscious decision!).

Blind interviews#

A lot of unconscious bias happens in interviews. It’s an unfair reality. You can’t help how you look, who you are, or how they adjust for their own biases, but just know that blind interviews exist to help mitigate that injustice. Interviewing.io, Byteboard, and Pramp even let you do practice interviews anonymously and actually get hired from there.

Take-home projects#

You can consider these as “enhanced technical interviewing.” They are wonderful for the new developer. I have had two job offers based on successful take-home projects. There is a lot of freedom in how you complete these:

• You can choose to go all out and risk being messy by showing how you would work on a real project (including architecting for scale and including other niceties that they didn’t ask for but would in real life), with a risk of failure.
• Or, you could do a minimal, super clean project that just checks all the required user stories and nothing more, making it extremely well documented and tested.

The judgment call relies on what they are really hiring you to do. I usually go for the risky option because it fits the jobs I seek. Note that take-home projects typically take between four hours to two days; any longer and the company should be paying you.

Over-communicate#

Comment freely in your code and, in general, find ways to demonstrate that you can communicate well. In one of my take-home projects, they set up a Slack channel to discuss my work with me, and I constantly spammed my channel with status updates as I did the project. They loved interacting with me and gave me the offer.

Non-technical/fit interviews#

Arrive early. Think of the most confident person you know and channel them just for this interview. You are on stage. You are not just interviewing for a role; you are playing a role. Smile. Keep eye contact. All the advice from How to Win Friends and Influence People works here. Have your self-intro rehearsed and in under a minute. Try to research your interviewers beforehand. Get them to talk (Most people love talking about themselves and find themselves liking you more the more they talk.).

Reverse interviews#

If someone asks if you have any questions, ask a question. This is known as a “reverse interview.” The most famous of these was the Joel test, which is a little outdated today. You can consider this updated list instead. Asking good questions about company culture can both make you look good (you appear serious about the job and also know how to ask good questions) and help you make your final decision. So it makes sense to prepare these questions beforehand!

“Convince me how you can help me, and you get into a special shortlist that almost nobody gets into.”

- Daniel Vassallo